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REMARKS 

Claims 1, 3, 5-8, 10, 1 1, 12-15, 17, and 19-21 are in the case. Applicants have amended 
claims 1,8, and 15 and cancelled claims 2, 4, 9, 11, 16 and 18 from further consideration 
in this application. Applicants are not conceding in this application that those claims are 
not patentable over the art cited by the Examiner. The present claim amendments and 
cancellations are only for facilitating expeditious prosecution of the present case. 
Applicants respectfully reserve the right to pursue these and other claims in one or more 
continuations or divisional patent applications. 

Claim Rejections - 35 U.S.C. § 102 Over Trossen 

Claims 1, 3, 5-8, 10, 11, 12-15, 17, and 19-21 stand rejected under 35 U.S.C. § 102(e) as 
being anticipated by Trossen, et al. (U.S. Publication No. 2003/0204599) (hereafter 
'Trossen'). "A claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art reference." 
Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). As explained in more detail below, Trossen does not disclose 
each and every element of claim 1, and Trossen therefore cannot be said to anticipate the 
claims of the present application within the meaning of 35 U.S.C. § 102(e). 

Independent claim 1, as currently amended, claims: 

1 . (Currently Amended) A method for administering devices, the method 

implemented with two data processing domains, a first domain and a second 
domain, each domain comprising a networked data processing environment, the 
domains coupled for data communications, the method comprising: 

receiving, in the second domain from the first domain, a domain state object, the 
domain state object comprising information representing a state of the first 
domain including information identifying devices within the first domain and a 
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current value of an attribute of those devices within the first domain and 
information describing a user's current condition within the first domain ; 

wherein receiving a domain state obiect comprises: 

receiving a signal to download the domain state obiect from a 
mobile sensor; and 



downloading the domain state obiect from the mobile sensor; 

identifying by the second domain an action in dependence upon the domain state 
object; and 

wherein identifying an action in dependence upon the domain state obiect 
comprises: 

retrieving a current device state object from the domain state 
object: 

selecting an action ID in dependence upon the current device state 
object. 

the second domain's executing the action. 

Trossen Does Not Disclose Receiving A Domain State 
Object, Identifying An Action In Dependence Upon The 
Domain State Object, Or Executing The Action 

The Office Action takes the position that Trossen at paragraphs 0024-0027, discloses 
every element of claim 1 as claimed prior to the current amendment: receiving a domain 
state object, identifying an action in dependence upon the domain state object, and 
executing the action. Applicants respectfully note in response, however, that what 
Trossen at paragraph 0024-0027, in fact discloses is: 
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[0024] Suppose now that the user desires to move MT 12 from the current 
WLAN administrative domain 15 to a new administrative domain 19 in 
communication with new access router 18 and new access network 20. 
Suppose also that the bandwidth in new administrative domain 19 is less 
than the WLAN administrative domain. This would typically be the case 
for example if the new administrative domain happens to be the outdoor 
cellular coverage. Because the session was established with higher 
bandwidth capabilities, the session may be unable to continue 
uninterrupted in its current state as regards resolution, speed of video 
motion, size of displayed pictures, color combinations, clarity of audio etc. 
Some of these parameters need to be changed so that the video stream can 
fit in the new bandwidth constraints. To achieve this, prior to handoff from 
access router 14 to access router 18, MT 12 constructs an application 
context for the video session and registers 72 it with current access router 
14. It may create the application context, for example, from information 
obtained in the SDP descriptive information in the SIP INVITE message 
from CS 22 and from MT 12's subsequent response. In order to register the 
application context, MT 12 formats the application context information 
into a pre-determined format that such access routers may accept. The pre- 
determined format may be according to a standard, such as one 
recommended by IETF. As an example, the standard format could be an 
object that could be used by an object-oriented application running on 
access routers 14, 18. Such object technologies, for example, may include 
Common Object Request Broker Architecture (CORBA), Distributed 
Component Object Model (DCOM), Simple Object Access Protocol 
(SOAP), Enterprise Java Beans (EJB), and Type Length Value (TLV). 

[0025] After MT 12 creates and formats the application context for the 
video session, it registers 72 the context by transferring it to current access 
router 14, for example, via IP messaging. Such IP messaging may make 
use of protocols, for example, like Internet Control Message Protocol 
(ICMP), User Datagram Protocol (UDP), Transmission Control Protocol 
(TCP), and Stream Control Transmission Protocol (SCTP). According to 
one aspect of the invention, the transfer of application context to current 
access router 14 occurs along with a handoff trigger message from MT 12, 
such as an indication of a reduction in signal strength. According to other 
aspects, the application context may be transferred at the beginning of the 
session, at handoff, or almost any other time therebetween. As shown in 
FIG. 6, registration 72 may occur at the beginning of the session prior to 
CS 22 sending 74 data to MT 12. Further, the application context may be 
periodically updated, such as when changes occur to sessions. Although 
discussed in combination with a video call scenario, the application 
context may include information about various types of applications and 
sessions and about multiple concurrent sessions and applications for MT 
12. 
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[0026] As diagrammed in FIG. 6, after MT 12 transmits the application 
context to current access router 14, current access router 14 receives the 
application context and transmits 76 the application context to new access 
router 1 8. The timing of the transfer between access routers 14 and 18 may 
vary. For example, if MT 12 registers the application context at the 
beginning of the session, access router 14 may simply store the application 
context in memory 56 until it anticipates a handoff. It may anticipate a 
handoff based on the reception of a handoff trigger from MT 12, or based 
on other information, such as by GPS tracking information for MT 12. 
Conversely, if MT 12 registers the application context along with a 
handoff trigger, access router 1 8 may immediately transfer the associated 
application context for MT 12 and its current sessions to new access router 
18. Transfer 76 of the application context for MT 12 and its sessions from 
router 14 to router 18 may occur via Internet communications using IP 
messaging. 

[0027] Upon reception of the application context, new access router 18 
evaluates the application context to determine whether steps are necessary 
to introduce application-specific functionality for the session. It may do 
this by comparing the parameters contained in the application context with 
corresponding capabilities for transmissions via access network 20 and 
communication capabilities for domain 19. For example, in the video call 
scenario, access router 18 may evaluate the application context and 
determine that the bandwidth for communicating with MT 12 in new 
administrative domain 19 is less than the established session, as originally 
supported by broadband WLAN administrative domain 15. As such, 
access router 18, in accordance with program instructions stored in 
memory 56, may establish a relationship with network entity 35 to provide 
necessary application-specific functionality for the session. In the case of 
the video call session, network entity 35 may be a transcoding proxy 
server 35 that transforms the high bandwidth video into low bandwidth 
video appropriate for transmission over the new wireless link. 

That is, Trossen at paragraphs 0024-0027, discloses an application context that may be 
formatted as an object that could be used by an object oriented application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain. Trossen's application context that 
may be formatted as an object that could be used by an object oriented application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain, does not disclose receiving a 
domain state object, identifying an action in dependence upon the domain state object, or 
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executing the action as claimed in the present application. A domain state object is 
recited in claim 1 as "comprising information representing a state of the first domain 
including information identifying devices within the first domain and a current value of 
an attribute of those devices within the first domain and information describing a user's 
current condition within the first domain." A domain state object is described at 
Applicant's original specification page 45, lines 10-20 as: 



The exemplary class diagram of Figure 3 includes a domain state object 
(914). The exemplary domain state object of Figure 3 includes a userlD 
(405) identifying the user. The exemplary domain state object of Figure 3 
includes a user's metric vector (606). In many examples, the metric vector 
is the user's current metric vector when the domain state object was 
created. The exemplary domain state object of Figure 3 includes a metric 
space (610). In many examples, the metric space (610) of the domain 
state object is the user's current metric space when the domain state object 
was created. The domain state object of Figure 3 also includes a current 
device state object "CDSO" (926). The current device state object (926) is 
a data structure including at least one device and the current value of an 
attribute of that device in the domain when the domain state object was 
created. 

Applicants further describe a domain state object at Applicants' original specification 
page 76, line 24 - page 77, line 5 as follows: 



In many examples of the method of Figure 13, a domain state object (914) 
is a data structure including information describing the state of the first 
domain and information describing the current condition of the user in the 
first domain (912). In various alternative embodiments of the method of 
Figure 13, the specific information contained in a domain state object will 
vary. Typical domain state objects however include information 
identifying devices within the first domain and the state or current value of 
an attribute of those devices. Typical domain state objects also include 
information describing a user's current condition within the first domain 
such as the user's current metric vector and the user's current metric 
space. 

As can be seen from claim 1 and these passages of Applicants' original specification, a 
domain state object is a data structure that includes information identifying devices, not a 
single device, within a first domain and a current device state object which is a data 
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structure including at least one device, not only a single device, and the current value of 
an attribute of that device in the domain when the domain state object was created. 
Trossen's application context is created, however, for only a single device, the mobile 
terminal (MT 12), and does not include information identifying more than a single device 
within a first domain or a current device state object that includes at least one device as 
described in Applicant's original specification. Trossen's application context that may be 
formatted as an object that could be used by an object oriented application, the 
application context created in order to move a mobile terminal (MT 12) from a current 
administrative domain to a new administrative domain does not disclose therefore a 
domain state object as claimed in the present application. Because Trossen does not 
disclose a domain state object as claimed in the present application it cannot be said that 
Trossen discloses receiving a domain state object, identifying an action in dependence 
upon the domain state object, or executing the action as claimed in the present 
application. Because Trossen does not disclose each and every element and limitation of 
Applicants' claims, Trossen does not anticipate Applicants' claims, and the rejections 
under 35 U.S.C. § 102(e) should be withdrawn. 

Relations Among Claims 

Independent claims 8 and 15 are system and computer program product claims for 
administering devices corresponding to independent method claim 1 that include "means 
for" and "means, recorded on [a] recording medium, for" administering devices. For the 
same reason that Trossen does not disclose a method for administering devices, Trossen 
also does not disclose systems and computer program products for administering devices 
corresponding to independent claims 8 and 15. Independent claims 8 and 15 are 
therefore patentable and should be allowed. 

Claims 3, 5-7, 10, 11, 12-14, 17, and 19-21 depend respectively from independent claims 
1, 8, and 15. Each dependent claim includes all of the limitations of the independent 
claim from which it depends. Because Trossen does not disclose each and every element 
of the independent claims, Trossen does not disclose each and every element of the 
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dependent claims of the present application. As such, claims 2-7, 9-14, and 16-21 are 
also patentable and should be allowed. 



Claims 1, 3, 5-8, 10, 1 1, 12-15, 17, and 19-21 stand rejected under 35 U.S.C. § 102 as 
being anticipated by Trossen. Trossen does not disclose each and every element of 
Applicants' claims. Trossen therefore does not anticipate Applicants' claims. Claims 1, 
3, 5-8, 10, 1 1, 12-15, 17, and 19-21 are therefore patentable and should be allowed. 
Applicants respectfully request reconsideration of claims 1, 3, 5-8, 10, 11, 12-15, 17, and 
19-21. 

The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 



Conclusion 



Date: June 21 2007 



By: 




H. Artoush Ohanian 
Reg. No. 46,022 
Biggers & Ohanian, LLP 
P.O. Box 1469 
Austin, Texas 78767-1469 
Tel. (512) 472-9881 
Fax (512) 472-9887 
ATTORNEY FOR APPLICANTS 
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